This invention is in the field of data analysis in the hydrocarbon industry, and is more specifically directed to data processing techniques used therein.
In the oil and gas industry, significant effort is spent in understanding the location, size, and contents of subsurface hydrocarbon reserves, both under land formations and also offshore. Of course, knowledge regarding these attributes of oil and gas reservoirs can, at best, be obtained indirectly, given their location. The field of oil and gas prospecting has developed many different approaches toward gathering the necessary information from which one can deduce the location of important oil and gas reservoirs (i.e., those reservoirs having sufficient accessible quantities of hydrocarbons that production is economically feasible). These various approaches include seismic prospecting, gravity surveys, magnetic field surveys, core sampling, and well logging, to name only a few. Modern oil and gas prospecting utilizes a combination of information gathered from these and other sources to predict the location of producible quantities of oil and gas.
Because of the wide array of sources of information used in the prospecting process, however, the combining and analysis of the information can be quite cumbersome, even using modern high-performance computing equipment. Typically, the analysis of this information is not performed by a single program or product, but instead a wide array of analysis techniques are typically available, each having a particular advantage or benefit in the analysis, but unfortunately each also requiring a particular expected input data format. Further exacerbating the difficulty of combining data in the analysis operation, similar data is typically obtained by tools or acquisition programs from different vendors, each with their own specific format and approach.
Of course, the geologist or reservoir engineer may use each vendor's analysis program on its own data to produce multiple reports or analyses; combination of these analyses may then be done in a qualitative or, at best, in a quantitative but non-automated manner. The analysis provided by this approach is, of course, less than optimal and is also quite time-consuming. Accordingly, there has been a need to communicate data from multiple sources and formats into multiple analysis programs for automated analysis. Referring now to FIG. 1, a conventional approach to using data from multiple sources with multiple analysis programs is illustrated.
FIG. 1 illustrates a conventional interrelationship of various databases and analysis tools to which an analysis application program may obtain data. In the conventional arrangement of FIG. 1, four databases V.sub.A through V.sub.D are provided. In this example, each of databases V.sub.A through V.sub.D is a conventional arrangement of data gathered from a particular type of tool or input arrangement. For example, database V.sub.C may be a well log database, in which data obtained from a well log tool is formatted and arranged according to a selected format. Similarly, databases V.sub.A, V.sub.B, V.sub.D are similar databases of other types of well logs, or of associated information such as seismic survey data and the like. In this example, as is typical in the art, databases V.sub.A through V.sub.D are provided by different vendors, and as such are not arranged in a common format. In this conventional example, the human analyst wishes to analyze the data from all four sources of databases V.sub.A through V.sub.D in an automated fashion using analysis application program 10, in order to determine the presence of a hydrocarbon reservoir. Analysis application program 10 is, as typical for analysis programs in the art, is designed for use with some, but not all, of databases V.sub.A through V.sub.D. In this example, analysis application program 10 corresponds with databases V.sub.A, V.sub.C by way of input/output links. For example, analysis application program 10 may be a program that correlates, or "ties", well log data from database V.sub.C with seismic survey data of database V.sub.A. In this example, only two of databases V.sub.A through V.sub.D are directly visible to analysis application program 10.
However, in the conventional arrangement of FIG. 1, the format incompatibility of databases V.sub.A through V.sub.D requires the generation of various translator programs so that data stored in one of databases V.sub.A through V.sub.D may be used in connection with analysis application program 10 associated with a different one of the databases V.sub.A through V.sub.D. Accordingly, in this example, twelve translator programs T.sub.AB through T.sub.DC must be written, installed, and maintained, in order for the data from any one of the databases V.sub.A through V.sub.D to be useful in connection with analysis application program 10. Each of these translator programs T is operated to translate the current database from each of the other formats into a copy contained in its resident format; for example, translators T.sub.AC, T.sub.BC, T.sub.DC each generate a copy of a respective one of databases V.sub.A, V.sub.B, V.sub.D and store this copy in database V.sub.C. As a result, four copies of each of the databases (one source original, and three translated copies) are resident in the system of FIG. 1.
The overhead programming and database maintenance required for the arrangement is thus substantial. In general, for N vendor databases V, N(N-1) translator programs T are necessary. As such, the addition of each incremental database for use in analysis requires the generation of multiple translator programs (e.g., eight new translators in the case of adding a fifth database V.sub.E to the arrangement of FIG. 1). In addition, the system manager must maintain a large number of input/output links (a minimum of fourteen such links in the case of FIG. 1, where a single analysis application program 10 is in place). The operation of the arrangement of FIG. 1 in performing prospecting or analysis is therefore extremely cumbersome.
In addition, the arrangement of FIG. 1 is also prone to error, considering that multiple copies of the same database are maintained. The system manager must therefore ensure the coherency of the source copy and all translated copies of each database, in the event that any copy is changed by addition, deletion, or editing. Such coherency maintenance is both time-consuming and expensive, and requires rigorous attention to the operation of the system.
The problems caused by data format incompatibilities, as discussed above relative to FIG. 1, are well known in the field of oil and gas data analysis. In response to these problems, database format standards have been proposed for use in the field. Of course, the incorporation of a standard would require conversion of new and existing databases from their existing format to the standard format. In addition, certain database types are maintained in specific formats that provide special benefits to their type of data; the benefits of these specific formats may be lost upon adoption of a "least common denominator" standard. Furthermore, the success of a standard depends upon the willingness of all industry participants to conform to the standard; such willingness is not assured, given the competitive nature of the industry.
By way of further background, object-oriented programming and design techniques are well known in the computer programming art. As fundamental in the object-oriented field, object-oriented computer programs treat merged units of code (computer program instructions) and data as "objects", where the details of the code and data stored in an object are encapsulated, and thus not visible to the outside user. Object-oriented programs communicate with the objects by way of specified "messages", which are functions that serve to read data from, write data to, and operate the objects as desired, according to the protocol of the particular language. Objects in object-oriented programs and databases are generally classified into a hierarchical arrangement of classes, where attributes of higher-level classes are "inherited", or applicable to, the objects in lower-level classes depending therefrom. An example of an object-oriented programming approach is known in the art as the "abstract factory", and is described in Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software, (Addison-Wesley, 1995), pp. 87-95, incorporated herein by this reference.
Conventional object-oriented programs have typically operated in connection with specific functions; for example, object-oriented statistical programs, object-oriented database programs, and 3-D computer-aided-design object-oriented programs are all known in the art, but operate upon objects that are specifically designed for their application type. The disjointed nature of these object-oriented programs from one another has precluded their use in a unified manner.
Heretofore, the application of object-oriented programming and design to the hydrocarbon database problem of FIG. 1 has not been accomplished for several reasons. Firstly, the databases used by the geologist or reservoir engineer come from vastly diverse sources, such as seismic surveys (which are themselves widely diverse, including such types as velocity surveys, 2-D and 3-D surveys, grids versus tessellated surfaces, etc.), well logs, magnetic or gravitational field surveys, well performance, and others. Secondly, the types of analysis applications that may be applied to the vastly diverse databases are also widely diverse, including such dissimilar applications as statistical evaluation, data translation, graphic visualization, interactive survey design, and the like. As such, the application of object-oriented program design to access the multiple formats of geological and geophysical data necessary to perform an integrated hydrocarbon survey analysis has not been successful to date.